feat(NODE-3517): improve index spec handling and type definitions#3315
feat(NODE-3517): improve index spec handling and type definitions#3315baileympearson merged 29 commits intomainfrom
Conversation
d08bfe3 to
20261ac
Compare
dc35940 to
0c03cf7
Compare
33d71dd to
79babb2
Compare
|
Requesting Review from: @aditi-khare-mongoDB (GH permission issues) |
| let collection: Collection; | ||
|
|
||
| beforeEach(async function () { | ||
| if (this.configuration.clientSideEncryption == null) { |
There was a problem hiding this comment.
What is this check for?
There was a problem hiding this comment.
It is to avoid the dependency missing error that will be thrown by the newClient call that takes an autoEncryption option.
There was a problem hiding this comment.
So if clientSideEncryption is nullish, we return. Is that supposed to skip these tests? If so, we should explicitly skip them and attach a skip reason.
Also, if that's the intention, should we follow the precedent we just set and use this.configuration.clientEncryption.enabled?
There was a problem hiding this comment.
The tests are skipped by the metadata attached to each test
| let indexes; | ||
| try { | ||
| expect(await collection.indexExists(operation.arguments.indexName)).to.be.true; | ||
| indexes = await listIndexCursor.toArray(); |
There was a problem hiding this comment.
Why did we change the implementation here? Is our indexExists broken?
There was a problem hiding this comment.
It asserted the reverse of what the operation expects (expected indexExists to return true for the assertIndexNotExists operation.) So it needed to be flipped but also we made the code the same as the code for assertExists, listIndexes is spec-ed so seems like we should use that in the spec test runner.
| export type IndexSpecification = OneOrMore< | ||
| | string | ||
| | [string, IndexDirection] | ||
| | { [key: string]: IndexDirection } |
There was a problem hiding this comment.
Removing the array options is a breaking change, because the following used to be permitted, even though it's not a valid index specification according to MongoDB:
const invalid: IndexSpecification = [[["name", 1]]]Our precedent is to release breaking TS changes as bug fixes when applicable, which I am okay with, but maybe we should consider pulling this change (the deletion of lines 60/61) into a separate bug fix PR to not mix the bug fix in with this other work.
There was a problem hiding this comment.
Of the three we're addressing here should we pull them each out and try and make this PR only about the refactor (i.e. why this bug but not the others)? (I think the tuple one might be difficult but we can see).
There was a problem hiding this comment.
what "three" are you referencing here? three bugs?
There was a problem hiding this comment.
- Map in TS
- Key order FLE
- Tuple parsing issue
- Type strictness on this nesting of array (one or more)
- Type strictness for createIndexes aligned with createIndex
There was a problem hiding this comment.
I think whether we pull these out into separate PRs/fixes or not, we should make sure that the PR description accurately reflects whatever fixes are included and that we are super clear in our release notes about the changes in behavior. It's also worth noting that the types in the documentation won't get updated on a patch, unless we manually regenerate the 4.8, which could be confusing. I think because of the scope of the changes here, this set of improvements that's coming in as a bug fix is better marked as a feat:
There was a problem hiding this comment.
Oh and let's triple check to make sure that every single one of those things has full regression test coverage
There was a problem hiding this comment.
Collected a summary in the description and between the type/fle/indexes.test.ts additions I see coverage for each point.
src/operations/indexes.ts
Outdated
| this.collectionName = collectionName; | ||
|
|
||
| this.indexes = indexes; | ||
| // Ensure we generate the correct name if the parameter is not set |
There was a problem hiding this comment.
Can we move this code into a function? We discussed this a bit in the office, but I still think for readability it should be broken out. The fact that a comment is necessary to explain what this block of code is doing strongly indicates that this should be broken out into a function.
baileympearson
left a comment
There was a problem hiding this comment.
requesting changes for visibility
Description
parseIndexOptions()was a helper function that allowed users to multiple different input formattings for CreateIndex and normalizes them to one format.The function was buggy, in the wrong file, and had some unused outputs, so I renamed it to
getFieldHashand put it inside themakeIndexSpecfunction.What is changing?
Is there new documentation needed for these changes?
Yes,
What is the motivation for this change?
Bug:
the previous
parseIndexOptionswas buggy when a [string, IndexDirection] tuple was part of the input.Desired Output:
{string: IndexDirection}Current Output:
(if IndexDirection is numerical)
{string: 1}OR
(if IndexDirection is not numerical):
{{string: 1} {IndexDirection: 1}New Feature:
Can now input a Map with a single key and value, or an array of length = 1 Maps as input.
** This is important as now we can preserve numerical key ordering **
Input Examples:
ex:
new Map<string, IndexDirection>([['sample_index', -1]])ex2:
[ new Map<string, IndexDirection>([['sample_index1', 1]]), new Map<string, IndexDirection>([['sample_index2', -1]]), new Map<string, IndexDirection>([['sample_index3', '2d']]) ]Addresses:
PR Summary:
createIndexwere incorrectly parsed as string inputcreateIndex(['myKey', 1])would create{ 'myKey': 1, '1': 1 }.Double check the following
npm run check:lintscript<type>(NODE-xxxx)<!>: <description>